Use effects for indirect call expressions by stevenfontanella · Pull Request #8625 · WebAssembly/binaryen

stevenfontanella · 2026-04-19T08:51:38Z

Part of #8615. After #8609, we compute effects for indirect call expressions, but only reflect this in the call-site via the effects of the Function that contains the indirect call. That let us reason about effects only one layer of indirection away, for example in the following module:

(func $a
  (call_ref $t (...))
)

(func $b
  (call $a)
)

If we know that an indirect call to $t can't possibly have any effects (e.g. its only potential target is a nop), we'd be able to optimize away (call $a) but not the (call_ref) itself, since the effects only got stored in the effects of $a.

This PR lets us reason about indirect call effects at the expression level within function bodies by adding a map from HeapType to effects typeEffects in wasm::Module. As a result we can completely optimize out the call_ref in the above example.

Drive-by fixes:

Set an unconditional trap effect on call_indirect when the call type doesn't match the target table.
Correctly set branchesOut for return_call on call.without.effects. Previously this would not have a branchesOut effect which may have allowed incorrect reorderings (we shouldn't move an effectful expression above a return_call but we would have allowed this). Will follow up in return_call with call.without.effects optimizes incorrectly #8693.

stevenfontanella · 2026-04-23T23:17:06Z

Seems like JJ + Github don't play well when I'm on a branch based on another branch that had a merge commit. Will fix this after merging the other branch.

When running in --closed-world, compute effects for indirect calls by unioning the effects of all potential functions of that type. In --closed-world, we assume that all references originate in our module, so the only possible functions that we don't know about are imports. Previously [we gave up on effects analysis](https://github.com/WebAssembly/binaryen/blob/29b2d42e8a748fbe1095696d58a52b7bf83e2253/src/passes/GlobalEffects.cpp#L83-L87) for indirect calls. Yields a very small byte count reduction in calcworker (3799354 - 3799297 = 57 bytes). Also shows no significant difference in Binaryen runtime: (0.1346069 -> 0.13375045 = <1% improvement, probably within noise). We expect more benefits after we're able to share indirect call effects with other passes, since currently they're only seen one layer up for callers of functions that indirectly call functions (see the newly-added tests for examples). Followups: * Share effect information per type with other passes besides just via Function::effects (#8625) * Exclude functions that don't have an address (i.e. functions that aren't the target of ref.func) from effect analysis () * Compute effects more precisely for exact + nullable/non-nullable references Part of #8615.

Gemini WIP Try changing call effects

aheejin · 2026-05-12T07:28:07Z

+        }
+      }
+
+      if (effects.throws_ && (parent.tryDepth > 0 || curr->isReturn)) {


When do we use effect.throws() and when to use effect.throws_?
(Should we use throws() in all cases?)

Good catch! throws() is throws_ || !delegateTargets.empty(). If we're delegated to and we catch, then it would be correct for throws() to be false, but it would remain true in our case because we can only clear throws_ (it wouldn't be right to just clear delegateTargets because it looks like it's used for other things too, even if the delegated exception gets caught). So we're overly pessimistic in this case.

This way preserves the existing logic (link) so I'd prefer to keep it as-is and fix it in a future PR. Let me try to repro a case where our effects are overly pessimistic and file an issue.

Maybe my memory of how this delegateTargets is working is patchy (even though it's probably me who added this..).

Good catch! throws() is throws_ || !delegateTargets.empty(). If we're delegated to and we catch, then it would be correct for throws() to be false

How can we at the same time be delegated to and catch? If we are a target of a delegate, that means we are try-delegate, not catch, no?

(it wouldn't be right to just clear delegateTargets because it looks like it's used for other things too, even if the delegated exception gets caught).

What are the other things it used for?

Anyway, keeping the existing logic as is in this PR and follow-up later sounds fine.

How can we at the same time be delegated to and catch?

I think this is the typical case for try-delegate? e.g. here I think the $outer_handler block is a delegateTarget and catches, so it should have no throw effect:

(func try $outer_handler try call $potentially_throwing_function delegate $outer_handler ;; Forwards the exception to the outer try block catch call $handle_error end )

OTOH we can also delegate to a block that doesn't catch at all, in which case that block needs to have a throw effect, e.g. here the anonymous block for the function body should have a throws effect:

(func try try call $some_throwing_function delegate 1 ;; Delegates to the caller, bypassing the outer try/catch catch ;; This catch block is completely ignored end )

(I just read about this feature now FWIW, so I could be wrong)

What are the other things it used for?

I thought it was used in another pass but after looking again it's just shadowing the name. Still, just clearing delegateTargets seems wrong; even if an expression catches exceptions, it seems misleading to say that it wasn't delegated to.

Ah right, your understanding is correct; I was confused. We handle the "catching" effect in catch_all (because tryDepth> 0) but still conservative because we don't check tag matches for catch, also we don't check whether the try-delegate body itself throws or not. Given that catch_all greatly outnumbers catch at least in C++ (due to destructors), I doubt fixing the former would be a meaningful win, but maybe the latter can be a good missed opportunity. Not sure.

binaryen/src/ir/effects.h

Lines 565 to 586 in 36b7033

static void doStartCatch(InternalAnalyzer* self, Expression** currp) {

Try* curr = (*currp)->cast<Try>();

// This is conservative. When an inner try-delegate targets the current

// expression, even if the try-delegate's body can't throw, we consider

// the current expression can throw for simplicity, unless the current

// expression is not inside a try-catch_all. It is hard to figure out

// whether the original try-delegate's body throws or not at this point.

if (curr->name.is()) {

if (self->parent.delegateTargets.contains(curr->name) &&

self->parent.tryDepth == 0) {

self->parent.throws_ = true;

}

self->parent.delegateTargets.erase(curr->name);

}

// We only count 'try's with a 'catch_all' because instructions within a

// 'try' without a 'catch_all' can still throw outside of the try.

if (curr->hasCatchAll()) {

assert(self->parent.tryDepth > 0 && "try depth cannot be negative");

self->parent.tryDepth--;

}

self->parent.catchDepth++;

}

Anyway I'm not still sure in what context "clearing delegateTargets" popped up, but anyway, I don't see any reason we should do it when handling calls.

kripken · 2026-05-12T21:50:39Z

+  // TODO: Use Type instead of HeapType to account for nullability and
+  // exactness.
+  std::unordered_map<HeapType, std::shared_ptr<const EffectAnalyzer>>
+    typeEffects;


How is this managed? Who is responsible for updating it? Please document this here.

kripken · 2026-05-12T23:02:38Z

+          it != parent.module.typeEffects.end() && it->second) {
+        bodyEffects = it->second.get();
      }
+      populateEffectsForCall(curr, bodyEffects);


Perhaps processCall or addCallEffects, which are shorter?

kripken · 2026-05-12T23:04:11Z

+    // GlobalEffects. Note that calls may have other effects that aren't
+    // captured by the function body of the target (e.g. a call_ref may trap on
+    // null refs).
+    template<typename CallType>


Suggested change

template<typename CallType>

template<typename T>

I believe this is the pattern we use in general.

kripken · 2026-05-12T23:06:05Z

+  using Ts::operator()...;
+};
+
+template<typename T> using NullablePtr = T;


What is this for?

kripken · 2026-05-12T23:07:44Z

+    template<typename CallType>
+    void populateFunctionBodyEffects(const CallType* curr,
+                                     const EffectAnalyzer& funcEffects) {
+      if (curr->isReturn) {


populateFunctionBodyEffects and populateEffectsForCall overlap here, I think? This is adding an effect from the call, not the body. Maybe I don't understand the difference between the functions - perhaps document them more?

aheejin · 2026-05-12T23:40:31Z

+        parent.trap = true;
        return;
      }
+      if (table->type.isNullable()) {


Is there a reason we check only this but call trapOnNull on visitCallRef? Should we call trapOnNull on both cases?

aheejin · 2026-05-12T23:41:33Z

-        parent.throws_ = true;
+      const EffectAnalyzer* bodyEffects = nullptr;
+      if (auto it = parent.module.typeEffects.find(curr->heapType);
+          it != parent.module.typeEffects.end() && it->second) {


Is there a case it->second is null?

stevenfontanella force-pushed the expression-effects branch from 690ee8d to 75481a7 Compare April 19, 2026 08:56

tlively reviewed Apr 20, 2026

View reviewed changes

Comment thread src/ir/effects.h Outdated

stevenfontanella force-pushed the indirect-effects-scc branch from 189d543 to 2630eff Compare April 21, 2026 20:15

stevenfontanella mentioned this pull request Apr 23, 2026

Compute effects for indirect calls in GlobalEffects #8609

Merged

stevenfontanella force-pushed the expression-effects branch from 75481a7 to 36a4fb5 Compare April 23, 2026 23:07

Base automatically changed from indirect-effects-scc to main April 24, 2026 21:36

stevenfontanella force-pushed the expression-effects branch from 36a4fb5 to e65a243 Compare April 24, 2026 22:16

stevenfontanella added 2 commits May 6, 2026 18:05

Use effects for indirect call expressions

58eb5c2

PR updates

253c092

stevenfontanella force-pushed the expression-effects branch 3 times, most recently from 30a31e1 to 60665f3 Compare May 7, 2026 20:33

WIP

2156d99

Gemini WIP Try changing call effects

stevenfontanella force-pushed the expression-effects branch from 60665f3 to 2156d99 Compare May 7, 2026 20:44

stevenfontanella marked this pull request as ready for review May 7, 2026 21:33

stevenfontanella requested a review from a team as a code owner May 7, 2026 21:33

stevenfontanella requested review from aheejin and removed request for a team May 7, 2026 21:33

aheejin reviewed May 12, 2026

View reviewed changes

stevenfontanella added 2 commits May 12, 2026 16:29

PR updates

7facc2a

Extract a common function for setting effects for function calls

5aac82a

kripken reviewed May 12, 2026

View reviewed changes

Comment thread src/ir/effects.h Outdated

Extract out fix for future PR

63d5515

stevenfontanella requested a review from aheejin May 12, 2026 20:45

kripken reviewed May 12, 2026

View reviewed changes

aheejin reviewed May 12, 2026

View reviewed changes

	static void doStartCatch(InternalAnalyzer* self, Expression** currp) {
	Try* curr = (*currp)->cast<Try>();
	// This is conservative. When an inner try-delegate targets the current
	// expression, even if the try-delegate's body can't throw, we consider
	// the current expression can throw for simplicity, unless the current
	// expression is not inside a try-catch_all. It is hard to figure out
	// whether the original try-delegate's body throws or not at this point.
	if (curr->name.is()) {
	if (self->parent.delegateTargets.contains(curr->name) &&
	self->parent.tryDepth == 0) {
	self->parent.throws_ = true;
	}
	self->parent.delegateTargets.erase(curr->name);
	}
	// We only count 'try's with a 'catch_all' because instructions within a
	// 'try' without a 'catch_all' can still throw outside of the try.
	if (curr->hasCatchAll()) {
	assert(self->parent.tryDepth > 0 && "try depth cannot be negative");
	self->parent.tryDepth--;
	}
	self->parent.catchDepth++;
	}

Conversation

stevenfontanella commented Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

stevenfontanella commented Apr 23, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stevenfontanella May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aheejin May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kripken May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

stevenfontanella commented Apr 19, 2026 •

edited

Loading

stevenfontanella May 12, 2026 •

edited

Loading

aheejin May 12, 2026 •

edited

Loading

kripken May 12, 2026 •

edited

Loading